Previous: SpamAssassin, Up: Thwarting Email Spam [Contents][Index]
A novel technique to fight spam is to require senders to do something costly and demonstrably unique for each message they send. This has the obvious drawback that you cannot rely on everyone in the world using this technique, since it is not part of the Internet standards, but it may be useful in smaller communities.
While the tools in the previous section work well in practice, they work only because the tools are constantly maintained and updated as new form of spam appears. This means that a small percentage of spam will always get through. It also means that somewhere, someone needs to read lots of spam to update these tools. Hashcash avoids that, but instead prefers that everyone you contact through e-mail supports the scheme. You can view the two approaches as pragmatic vs dogmatic. The approaches have their own advantages and disadvantages, but as often in the real world, a combination of them is stronger than either one of them separately.
The “something costly” is to burn CPU time, more
specifically to compute a hash collision up to a certain number
of bits. The resulting hashcash cookie is inserted in a
‘X-Hashcash:’ header. For more details,
and for the external application hashcash you need
to install to use this feature, see http://www.hashcash.org/. Even
more information can be found at http://www.camram.org/.
If you wish to generate hashcash for each message you send,
you can customize message-generate-hashcash (see
Mail Headers in The Message Manual), as in:
(setq message-generate-hashcash t)
You will need to set up some additional variables as well:
hashcash-default-paymentThis variable indicates the default number of bits the hash collision should consist of. By default this is 20. Suggested useful values include 17 to 29.
hashcash-payment-alistSome receivers may require you to spend burn more CPU time than the default. This variable contains a list of ‘(addr amount)’ cells, where addr is the receiver (email address or newsgroup) and amount is the number of bits in the collision that is needed. It can also contain ‘(addr string amount)’ cells, where the string is the string to use (normally the email address or newsgroup name is used).
hashcash-pathWhere the hashcash binary is installed. This
variable should be automatically set by
executable-find, but if it’s
nil (usually because the hashcash
binary is not in your path) you’ll get a warning when
you check hashcash payments and an error when you generate
hashcash payments.
Gnus can verify hashcash cookies, although this can also be
done by hand customized mail filtering scripts. To verify a
hashcash cookie in a message, use the
mail-check-payment function in the
hashcash.el library. You can also use the
spam.el package with the
spam-use-hashcash back end to validate hashcash
cookies in incoming mail and filter mail accordingly (see
Anti-spam Hashcash Payments).
Previous: SpamAssassin, Up: Thwarting Email Spam [Contents][Index]